【第2401期】每个开发人员都应该避免的常见的NPM错误

前言

今日前端早读课文章由@Ada_lake翻译分享。

正文从这开始~~

Learn how to avoid common mistakes when managing dependencies, publishing packages, and more.

了解如何避免在管理依赖关系、发布软件包等方面的常见错误。

NPM is the world’s largest package manager, and using it in practice is relatively straightforward. However, when adding custom configurations or using its advanced features, many things could go wrong.

NPM是世界上最大的包管理器, 在实际操作中使用它相对来说也比较简单易上手. 然洱，在自定义配置或者使用它相对高级的功能时，很多时候还是容易出错。

So, in this article, I will discuss seven common mistakes you should avoid when using NPM.

因此，在本篇文章中，我将介绍7种在使用NPM过程中时你应当去避免出现的错误。

1. Manually adding dependencies to package.json

手动为package.json添加依赖

You should avoid updating the package.json manually since it could break the synchronization between package.json and package-lock.json.

你应该避免手动更新package.json，因为它可能会破坏package.json 和 package-lock.json之间的同步。

Instead, you can use CLI commands like npm i --save and npm i --save-dev to update package.json and package-lock.json automatically. This will also alert you if there are any version mismatches in those 2 files.

你应该使用像npm i --save 和 npm i --save-dev这种命令行的方式来自动更新package.json 和 package-lock.json。如果这两个文件中存在任何版本不匹配，这也能够及时提醒您。

However, using CLI commands doesn’t always guarantee a smooth dependency upgrade process.

然而，使用CLI命令并不总能保证平稳的依赖项升级过程

For example, if you execute npm i --save package@~1.0.0, you could expect an @version pattern to be mirrored in the package. But Instead, we can use the ^ symbol to save the version with provisions upgrade in package.json.

举个例子，如果你想执行npm i --save package@~1.0.0这个命令,你可以期望在包中镜像一个 @version 模式。但是，我们也可以使用^符号来保存在package.json中带有配置升级的版本。

So, always double-check your package.json after updating dependencies.

因此，在更新依赖之后，请务必仔细检查你的package.json。

2. Locking your peer dependencies to a specific patch version

将您的对等依赖项锁定到特定的补丁版本

Usually, the peerDependencies are used to avoid duplicate installations of the package dependencies. And, it will be annoying if we lock the peer dependencies to a specific patch version. So, let’s take a simple example to understand the fundamental reason behind this issue.

通常情况下，peerDependencies是为了避免重复安装依赖包。而且，如果我们将对等依赖项锁定到特定的补丁版本，会使人很恼火。因此，让我们举个简单的例子来理解这个问题背后的根本原因。

{
  "name": "tea-latte",
  "peerDependencies": {
    "tea": "1.x"
  }
}

According to the above code, the tea-latte module depends on a specific version (e.g.: 1.x) of the tea package.

根据上述代码可知，tea-latte模块是依赖于tea包的一个特定的版本（比如：1.x）。

But, there can be other packages or modules in your project that depend on the latest version of the tea package. Therefore, locking the tea package for an older version can cause unexpected behaviors in your application.

但是，您的项目中可能还有其他包或模块依赖于最新版本的tea包。因此，锁定旧版本的 tea 包可能会导致应用程序出现意外行为。

Note: If peer dependencies are not explicitly dependent upon higher versions in the dependency tree, NPM versions 1, 2, and 7 will install them automatically. Versions 3,4,5 and 6 will give you a warning message.

注意：如果对等依赖项没有明确依赖依赖树中的更高版本，NPM 版本 1、2 和 7 将自动安装它们。版本 3、4、5 和 6 会给您一条警告消息。

3. Publishing multiple modules as a single package

将多个模块发布为单个包

一个独立的源代码控制和共享的“卡片”组织。在右侧的依赖关系图中，是由[Bit]自动生成的 (bit.dev/)。

Whether it is a UI library, a utility “toolbox”, or any other group of modules, it is almost always a bad idea to publish them all as a single package.

它是否是一个UI库，一个实用的工具箱，或者是任何其他的模块组，总之，将它们整合成单一的一个包并不是一个好主意。

There’s no reason why we should force consumers of our code to couple their project to an entire set of modules or components when all they need is a sub-part of it. They should choose what to use and which version of it, and they should never have to deal with meaningless updates.

我们没有理由在开发者只需要使用某一部分子模块时，强迫他们将他们的项目与一整套模块或组件耦合。他们应该能够自由选择使用什么以及什么样的版本，同时，他们也不应该被强迫去处理没有意义的更新问题。

Most chances are that you agree with me but dread the thought of managing a monorepo to maintain all these packages. To that I say, fear not!

大多数的时候你都会同意我的想法，但是害怕管理一个 monorepo 来维护所有这些包的想法。对此我说，不要害怕！

The JS ecosystem has come a long way since the days of the monorep-polyrepo dichotomy.

自 monorepo-polyrepo 二分法时代以来，JS 生态系统已经走过了漫长的道路。

We are now fortunate to be able to source-control and publish independent components from simple CRA-like projects, with auto-generated package.json , documentation, and more.

我们现在很幸运能够从简单的类似 CRA 的项目中进行源代码控制和发布 独立组件 ，带有自动生成的package.json、文档等。

4. Publishing sensitive data by accident

意外发布敏感数据

If you publish a module that contains sensitive information by accident, the first thing you might do is unpublishing the package.

如果您不小心发布了包含敏感信息的模块，可能要做的第一件事就是取消发布包。

But, once a module is published, it gets copied to all registry mirrors. Unpublishing it won’t make a difference.

但是，一旦发布了一个模块，它就会被复制到所有注册表镜像。取消发布它不会有什么不同。

Whitelists are a handy technique to secure what you publish in the registry and avoid accidentally releasing sensitive data.

白名单 是一种方便的技术，可以保护您在注册表中发布的内容并避免意外发布敏感数据。

All you need to do is modify the package.json with a property namedfiles. with files property, you can easily specify files or directories you need to publish.

您需要做的就是使用名为“files”的属性修改“package.json”。使用 files 属性，您可以轻松指定需要发布的文件或目录。

{
 “name”: “my-package”,
 “version”: “1.0.0”,
 “description”: “my-package”,
 “scripts”: {
 “test”: “echo \”Error: no test specified\” && exit 1"
 },
 “files”: [
 “dist/”
 ],
 “keywords”: [],
 “author”: “bhagya-withana”
}

So I recommend using whitelists to control which files are included in your next package.

所以我建议使用白名单来控制下一个包所要包含的文件

5. Providing a regular authentication token

提供定期的身份验证令牌

If you use private modules in a CI/CD pipeline, you need to provide an authentication token. However, NPM CLI doesn’t allow to control read and write access when generating these tokens.

如果你在CI/CD 管道机制中使用了私有模块，你需要提供身份认证的信息。然而，在生成这些令牌时，NPM CLI 不允许控制读写访问。

You manually generate a token using the public registry API and avoid any security vulnerability caused by tokens.

您使用公共注册表 API 手动生成令牌，并避免由令牌引起的任何安全漏洞。

The below command will generate a token with read-only access for you.

以下命令将为您生成一个具有只读访问权限的令牌。

curl -u [USERNAME]:[PASSWORD] https://registry.npmjs.org/-/npm/v1/tokens \
-X POST -H 'content-type: application/json' \
-d '{"password":"[USERNAME]", "readonly": "true"}'

Also, you can review, add, and delete the tokens you have created using the NPM website.

此外，您可以查看、添加和删除您使用 NPM 网站创建的令牌。

您的个人资料下的令牌选项

6. Upgrading for the sake of upgrading

为了升级而升级

Maintaining the latest versions is a good practice. However, you should not upgrade your packages just because there is a new version. Let’s find out why.

维护最新版本是一种很好的做法，但是，您不应该仅仅因为有新版本就升级您的软件包。让我们看看是为什么。

There are few reasons for that,

主要有以下几点原因

• There can be bugs in the latest versions.

最新版本可能会有新的bug。

• Version upgrades without proper study can cause unexpected behaviors in your application.

当你在应用时出现了问题，新版本没有合适的参考文献。

• New features might not be useful for your project.

新的功能可能对你的项目并不会有用。

• Need to consider the dependencies between other packages.

在其他包中可能需要考虑一些以来。

So, you need to evaluate the changes and compatibility of the new upgrade before updating your project’s library dependencies.

因此，在更新你的项目库依赖之前，你需要预估和比较一下最新的版本。

7. Deleting package-lock.json

删除package-lock.json

Deleting package-lock.json file to resolve NPM issues has become a common practice among developers.

为了解决NPM问题，删除package-lock.json 文件已经变成了大部分开发者常用的解决方案。

However, we should avoid this since the package-lock.json file keeps track of the exact version of every package installed. 

但是，我们应该避免这种情况，因为package-lock.json 文件会跟踪安装的每个包的确切版本。

For example, if you run npm update, upgraded versions of the dependencies will be reflected in the package-lock.json file.

例如，如果你运行npm update，升级后的依赖版本将反映在package-lock.json文件中。

So, instead of deleting package-lock.json file, you can try the below options.

所以，你可以使用以下方法来代替删除package-lock.json

• Solve the package.json conflicts.

解决package.json冲突。

• Take out package-lock.json from the main branch.

从主分支将package-lock.json移除。

• Run npm install again.

再次运行npm install。

Final Thoughts

小结

NPM is an essential part of any JavaScript-based project, and it helps developers install and manage packages efficiently.

NPM是任何基于 JavaScript 的项目的重要组成部分，它能够帮助开发者有效的安装和管理包。

But, we make many mistakes when using NPM, and some of them can cause serious issues. And, in this article, I discussed 7 such mistakes we make and best practices to avoid them.

但是，当我们使用NPM时可能会遇到很多问题，有时候可能这些问题比较棘手。因此，在这篇文章中，我列举出了7类我们可能会遇到的问题已经最好的解决方式。

So, I hope you will use them in your project from here onwards, and if you have any suggestions, please share them in the comments section.

因此，从这里开始，我希望你能够使用它们。如果你有任何的问题，请在评论去进行留言。

Thank you for Reading !!!

感谢阅读！

关于本文
译者：@Ada_lake
译文：https://juejin.cn/post/7005838413337198599
作者：@Bhagya Vithana
原文：https://blog.bitsrc.io/common-npm-mistakes-every-developer-should-avoid-60ab0642d8f9

为你推荐

欢迎自荐投稿，前端早读课等你来。

来自@Yevhen Kozlov的评论：

如果只是合并冲突，那么就没有必要 "从主分支中取出package-lock.json"：在解决了package.json中的冲突后，我们运行npm install，NPM就会为我们解决package-lock.json中的所有合并冲突。